Cloud-computing providers offer various services according to different models, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). These models offer increasing abstraction and are typically portrayed as a layers in a stack, where IaaS is a bottom layer, PaaS is a middle layer, and SaaS is a top layer. The models may also be used independent of each other.
IaaS cloud providers supply resources on-demand from large pools of equipment installed in data centers and typically bill services on a utility computing basis where a customer's cost is based on the amount of resources allocated and consumed. Cloud management solutions are available to customers that include system management and pattern engine capabilities to enable workload deployments in an IaaS environment. Some cloud management solutions allow a system administrator to select their own hardware (network/storage/compute) and virtualization software (hypervisors, etc.) to create their own cloud environment. This presents a unique challenge for customers when they have a large selection of hardware and software from which to configure for executing their specific workloads and requirements.
As used herein, the term “cloud environment” encompasses hardware, software (including hardware and software configuration), networking, and executing workloads. A cloud environment may include software at all three levels discussed above (IaaS, PaaS, and SaaS), may include information associated with a public cloud provider account, and may include an entire “rack” or datacenter in an on-premise private cloud. The way in which a cloud environment operates is typically subject to a numerous set of configurable parameters that typically include the following: hardware selection (CPU, disk, network cards, memory, routers/switches, etc.), firmware level selection, BIOS configuration, operating system selection for each hardware component, operating system configuration, virtualization software selection and configuration, and pattern deployment software/configuration. Within each of these components, configurable parameters are typically documented in a specific component's documentation.
A typical software virtualization software product may have hundreds of cloud-related configuration options (sometimes herein referred to as a “cloud environment configuration parameters”). A cloud environment configuration parameter, as that term is used herein, refers to a configurable setting of a cloud environment where the setting relates specifically to the fact that cloud is being used. For example, when an IT professional chooses a preference as far as which cloud is used to perform a given employee's computing work, then that is a cloud environment configuration parameter. As a further example, when an IT professional chooses which login options (for example, normal user, power user, administrator) with which a given employee will be presented by her cloud environment at startup time, then this is not a cloud environment configuration parameter because it does not specifically relate to cloud usage (except in the trivial sense that the setting happens to be present in a cloud environment implementation end user application). Configurable parameters that do not specifically relate to cloud usage are herein referred to as non-cloud configuration parameters. Cloud environment configuration parameters and non-cloud configuration parameters are herein collectively referred to simply as “configuration parameters.”
Typically, the configuration parameters of a cloud environment are manually configured for each component based on a system administrator's cloud requirements by those skilled in the specific component, which often requires multiple experts across various disciplines. The cloud requirements are created and manually maintained by the system administrator and only changed over time as the system administrator deliberately modifies the cloud requirements. The process of mapping the cloud requirements to specific configuration settings of components are contained within various components' reference documentation or derived from experts in the field.